The present invention is related to recovery of database objects in a computer system, and in particular to the system management of which objects to log in order to speed recovery processing after an abnormal system termination, while minimizing run-time impacts.
In a database system, recovery processing is normally required after an abnormal system termination in order to ensure that the integrity of the data within the database is preserved. Typically, database objects that were open at the time of the termination may need selective recovery actions performed. Objects are files of stored information, and usually include header data that describes or encapsulates the stored information.
Databases may be comprised of tables, that contain rows, and database indexes that provide ordered access to these rows, based on key values contained in the rows. As an example, rows might contain information such as a list of employees, their serial numbers and telephone numbers. One index might be ordered chronologically by employee serial number, while another index might be ordered alphabetically by employee name. When changes are made to the rows, database indexes over the table may need to be updated in order to keep tile indexes synchronized with the tables to which they refer.
When the system terminates abnormally, e.g. a power failure, the tables and the related indexes might not be synchronized. Some transactions may have caused index(es) to be updated, but the associated rows may not have been updated on non-volatile storage at the time the system terminated, or vice versa. Recovery processing after an abnormal system termination can thus include reading every row in every table, and rebuilding each of the indexes from the table rows. Depending on the number, size, and complexity of the database objects that are open when the system terminates, this recovery processing may take hours or even longer, during which time these objects may not be available to the user. This lengthy unavailability may be unacceptable to many users.
A well known approach for alleviating the lengthy time to recover objects after an abnormal system termination is through the use of a write-ahead log to record changes to the data objects prior to the changes being made to the objects in the database itself. Under this approach, the user specifies which objects he would like logged, and then the system logs or writes all changes for the objects to a separate log in non-volatile storage so that in the event of a failure, the log can be read and only the suspect data need be fixed.
While logging provides good data recovery and reduces the amount of time taken for post abnormal system termination recovery, it does so at the price of substantial run-time performance degradation due to the extra processing needed to log all the changes. For many users, this run-time performance degradation is unacceptable.